Simple database design-there's a temple in the mountains

Recently in the learning database, but rarely see the design reference that is suitable for getting started, so write down one's own actual

Designed for forgetting.

First, let's tell a story:

There used to be a mountain, there was a temple in the Mountain (temple), there lived an old monk (monk) in the temple, he gave small and
The story is like this: there were many temples on this mountain, and there were more than one mountain
Temple, there are temples near many mountains, but no temple can be built on two or more mountains, nor
The names of any two temples are repeated. Each monk can only belong to a temple, they all have a fahao, and
The Fahao is not repeated. When a monk's age is high enough (the threshold for each temple is different),
He could be an old monk. Each temple must have an old and Ganpat host, the ordinary Monk is not to live
The. Of course, an old monk can only preside over the temple he belongs to and not the other temples. Every day the monks were
Have to do homework, such as to the river water, go to the well water, to the backyard chanting, to the playground to practice, to the hall
Maintain order and so on. Did not say Monk can not go to the river to practise or to the hall chanting. Each location has the most
Large capacity. There is a schedule in the temple to record what time the monk should go to do his homework every day, and
Monks do not go to the same place on the same day to do the same type of homework two times. Every time he finishes his homework, the monk will give
A particular old monk reported. What monks are most willing to do is manage the merit book. A monk can
Manage multiple merit books, and a merit book can also be managed by more than one monk. Each merit book will have a number
In case you get confused. A number of pilgrims were recorded on the merit book, including their names and gender, as well as his
The total amount of our historical donations. A pilgrim's message will only appear on a merit book, in order to prevent it from being confused,
Information about pilgrims of the same name and gender will be recorded on different merit books. This problem is very important, because
For other temples, the confusion caused the pilgrims to go bankrupt.

The story is finished, then the question comes:

Extract the entities and their properties and represent them through the ER model, the ER model will be

What's it like?

The following is a simple design

Related issues discussed:

1) Should the mountain be an entity set or a property? Why?

Entity set. Mountain has a mountain name, location and other properties, mountain and Temple is a one-to-many relationship, if set as a property there will be a lot of redundant information.

2) What is the main code of the schedule?

{Start time, end time, type, place name, Fahao}

3) Whether to use aggregation, where to use, why use aggregation?

To use. The old monk supervised the monk's homework. There are relationships that make old monks this entity set and associated set execution.

4) is the Pilgrim a weak entity, and if so, how is the only certainty of a pilgrim?

Is. Use {Merit Book number, name, gender, historical donation sum}

Simple database design-there's a temple in the mountains