Sursa: http://www.databasedev.co.uk/data_models.html, data accesare 02.05.

2010

1
TEMA 1 - DVD Collection Scenario

The following data model is designed to hold information relating to a personal DVD collection. For this
scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The Entities required should include:
• Actors
• Film Titles
• Film Genres
• Actor Roles
• Producers
• Film Certificates
The Entities are related as follows:
• An Actor can be involved in many Films, in different Roles
• A Film can have many Actors
• A Film Genre can have many different Films
• A Film Certificate can have many Films
• A Film can have many Producers
• A Producer can produce many Films
When asking questions of the database we may need to know:
1. Who stared in a particular film, in what role?
2. Do you have any PG certified films in your collection?
3. Who were the Producers of a particular film?

2
TEMA 2 - Nursery/Childs Playgroup Scenario

The following data model is designed to hold information relating to a child's nursery/playgroup. For this
scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Children
• Parents
• Nursery Sessions
• Nursery Register
The Entities are related as follows:
• A Parent can have many Children
• A Child can have multiple Parent details recorded
• The Nursery holds many different Sessions (a session could be a Monday morning 8:00am -
12:00pm)
• A Child could be Registered against many Sessions (the child may go to nursery only three
mornings a week)
When asking questions of the database we may need to know:
1. Can we locate the preferred contact details of a particular childs parents
2. How many children are registered for each session this week
3. How much does each Parent owe in nursery fees for their children

3
TEMA 3 - Hotel Room Booking Scenario

The following data model is designed to hold information relating to a Hotel Room Booking System.
For this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
A local hotel needs a system that keeps track of its bookings (future, current and archived), rooms and
guests. A room can be of a particular type and a particular price band. Room prices vary from a room to a
room (depending on its type, available facilities, band, etc.) and from a season to a season (depending on
the time of the year).
A room booking can include more than one room and more than one customer.
The draft facts have been defined as:
The Entities required should include:
• Customers
• Guests
• Rooms
• Bookings
• Payments
• Room Types
• Price Bands
• Room Facilities
The Entities are related as follows:
• A Customer can make one or many Bookings.
• A Booking can be for one or many Guests - the Guest is not necessarily the person who makes the
Booking.
• A Room can be on one or many Bookings.
• A Room may have many different Room Facilities.
When asking questions of the database we may need to know:
1. How many rooms are currently available for booking?
2. What facilities are available in particular rooms?
3. Which Guests are booked in this week?

4
TEMA 4 - Employees and Qualifications

The following data model is designed to hold information relating to Employees and Qualifications that
each has achieved. For this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Employee Details
• Departments
• Employee Qualifications
• Qualifications
• Qualification Types
The Entities are related as follows:
• One Department can have Many Employees
• One Qualification Type can have Many Qualifications
• One Employee can achieve Zero, One or Many Qualifications
• One Qualification can be achieved by Zero, One or Many Employees
The design allows an Employee to be assigned to many Qualifications. Some Qualifications may have an
expiry date (they may only be valid for a set period of time), therefore we need to allow the Qualification
to be assigned to an Employee many times, hence the inclusion of the DateQualificationAchieved as part of
the composite Primary Key.
When asking questions of the database we may need to know:
1. Which Qualification does each Employee hold?
2. How many Qualifications are held by each Employee?
3. Have any Qualifications expired and need to be renewed by Employees?

5
6
TEMA 5 - Students, Courses and Tutors Scenario

The following data model is designed to hold information relating to Students, Student Courses and Tutors
who deal with these students. For this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Student Information
• Courses
• Student Courses
• Employees (Tutors)
• Contact Information (Contact between the Student and the Tutor by e-mail, phone, projects etc.)
• Contact Types (e-mail, phone, projects, assessments)
The Entities are related as follows:
• One Student can enroll on One or Many Courses
• One Course can have One or Many Students enrolled on it.
• One Student can have zero, one or many forms of Contact with the Course Tutor
• One Employee (Tutor) can deal with many Contacts
• One Contact Type (Phone, E-mail, Assessments, Projects etc.) can have zero, one or many Contacts
The design allows a Student to enroll on multiple Courses, with a Course having many Students enrolled
upon it. The Student may be in contact with the Course Tutor many times using many different forms of
Contact. A Tutor will deal with many contacts involving many Students.
When asking questions of the database we may need to know:
1. How many Students are enrolled on a particular Course?
2. Which Students are due to expire shortly?
3. When was the last contact made between a particular Student and a Tutor?
4. How many Students do we have from a particular County?
5. Which Course is the most popular?
6. How many currently enrolled Students do we have?

7
8
TEMA 6 - Football or Soccer Team Players and Fixtures scenario

The following data model is designed to hold information relating to Teams, Players and Fixtures for a
Football or Soccer Team. For this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Teams
• Players
• Fixtures
• Player Positions
• Competitions
The Entities are related as follows:
• One Team can have Many Players
• One Player can play in Many Fixtures
• One Fixture has Many Players
With this design, One Team has many Players, however a Player can only play for One Team at any one
time. The relationship between Players and Fixtures in a Many-To-Many relationship. One Player can play
in zero, one or Many Fixtures, and the Fixture involves Many Players. The link table between this
relationship also allows you to record whether a Player scored any Goals in that particular Fixture.
When asking questions of the database we may need to know:
1. Which Players played in a particular Fixture?
2. What was the result of a particular Fixture?
3. Which Players does a particular Team have signed on?

9
TEMA 7 - Vehicle Details and Information Scenario

The following data model is designed to hold information relating to Vehicle Details, in particular Vehicle
Manufacturers, Models and associated Vehicle information. For this scenario we need to define the
following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Vehicle Manufacturers
• Vehicle Models
• Vehicle Details
• Vehicle Features
• Vehicle Fuel Types
• Vehicle Colour
The Entities are related as follows:
• One Vehicle Manufacturer can have zero, one or many Vehicle Models
• One Vehicle Model can have zero, one or many Vehicle Details
• One Vehicle Fuel Type can have zero, one or many Vehicle Details.
• One Vehicle can have zero, one or many Vehicle Features, a Vehicle Feature can be associated with
many Vehicle Details
The design allows a Vehicle to have multiple Vehicle Features (Air Conditioning, Alloy Wheels, CD
Player, Electric Windows etc.) assigned to it. These Vehicle Features can also be associated with many of
the Vehicles, therefore we have a Many-To-Many relationship defined. This is broken into the two separate
One-To-Many relationships shown using the LINK table - tblLINKFeaturesToVehicles.
When asking questions of the database we may need to know:
1. How many Models does a Manufacturer make?
2. Do we have any Vehicles of a particular Model?
3. Do we have any Vehicles in stock that have Air Conditioning and Satellite Navigation?
4. Do we have any Vehicles manufactured by Ford for under £10,000
The following data model allows these questions to be answered and allows the information contained
above to be stored logically and in a structured manner.

10
11
TEMA 8 - Personal Contacts, Addresses & Contact Details scenario

The following data model is designed to hold information relating to Address Details and Personal Contact
Information and Contact Numbers. For this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Addresses
• Occupants
• Contact Types
The Entities are related as follows:
• One Address can have zero, one or many Occupants
• One Occupant can have zero, one or many Contact Types
• One Contact Type can have zero, one or many Occupants.
The design allows an Occupant to have multiple Contact Types (home phone, work phone, mobile phone,
fax number or e-mail addresses) assigned to them. The Occupant can also have the same type of Contact
Type associated with them multiple times, due to the composite Primary Key applied in the LINK table -
tblOccupantContactDetails.
When asking questions of the database we may need to know:
1. How many Occupants live at a certain Address?
2. What is the main Contact Number or E-mail address of a certain Contact (Occupant)?
3. Can we contact an Occupant using an alternative contact detail?

12
TEMA 9 - Golf Clubs and Membership Handicaps Scenario

The following data model is designed to hold information relating Members of a Golf Club and hold
information relating to Members, Courses, Golf Rounds and Handicaps. For this scenario we need to define
the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Members
• Courses
• Course Hole Details (Information relating to a Hole at a Golf Course)
• Golf Rounds (Rounds played by Members)
• Player Handicaps
The Entities are related as follows:
• One Member (Player) can play Many Golf Rounds
• One Player can have Many Handicap Reports (Date Dependant)
• One Golf Course can have Many Golf Holes (including Yardage and Par information)
• One Golf Course can provide Many Golf Rounds
The design allows a Member (Player) to submit many Golf Round reports from differing Golf Courses,
detailing scores made. This score information will go towards the Players Golfing Handicap.
When asking questions of the database we may need to know:
1. How many Members (Golf Players) belong to the Golf Club?
2. What score did a particular Member make when playing at a particular Golf Course?
3. What is the Players current Golf Handicap?

13
TEMA 10 - Motor Vehicle Insurance Policy Management Scenario

The following data model is designed to hold information relating to Motor Vehicle Insurance Policies. For
this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
An insurance company writes policies for drivers. One policy can cover many drivers and also many
vehicles, but a vehicle can be related to only one policy. Drivers can share one or more vehicles (e.g. a
husband and wife own one vehicle and they both drive the same vehicle or a family can have multiple
vehicles).
The company gets a master list of violations from the Department of Motor Vehicles. These violations are
then input into the system and used to determine the price of the policy. A driver may commit more than
one violation. One or more drivers can commit the same violation. The system should keep a track of all
customers - active (with insurance) and inactive (held in an archive – for cancelled customers). All
customers should be able to get a quote, insurance or cancel the insurance.
The draft facts have been defined as:
The Entities required should include:
• Drivers
• Vehicles
• Policies
• Insurance Groups
• Violations
• Link_VehiclesDrivers
• Link_ViolationsDrivers
The Entities are related as follows:
• The relationship between the tblVehicles and tblDrivers tables is Many-To-Many (a vehicle may be
driven by one or more drivers; a driver may drive one or more vehicles), so a link table should be
created (e.g. tblLink_VechiclesDrivers).
• The relationship between the tblVehicles and tblInsuranceGroups tables is One-To-Many (a vehicle
may belong to only one insurance group; many vehicles can belong to the same or different
insurance groups).
• The relationship between the tblViolations and tblDrivers tables is Many-To-Many (a driver may
commit one or more violations; a violation may be commited by one or more drivers), so a link
table should be created (e.g. tblLink_ViolationsDrivers).
• The relationship between the tblPolices and tblVehicles is tables is One-To-Many (a policy can
cover one or more vehicles; a vehicle can be covered and related to only one policy).
When asking questions of the database we may need to know:
1. How many violations has Driver 'X' had
2. Has Driver 'X' previously been insured with us
3. What insurance group is [car type here]
4. When does Driver 'X's Policy run out.

14
RELATIONSHIP PT. TEMA 10

15
TEMA 11 - Fishing Lakes and Members Scenario

The following data model is designed to hold information relating Members of a Fishing Lake and hold
information relating to catches made at these lakes. For this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Members
• Lakes
• Swims (Positions in the Lakes)
• Catches
• Species
The Entities are related as follows:
• One Member can submit Many Catch Reports
• One Lake can contain Many Swims
• One Swim can produce Many Catch Reports
• One Species can relate to Many Catch Reports
The design allows a Member to submit many catch reports, detailing dates and times of a particular catch
that has been made. The catch report will detail which species has been caught from which swim on a
particular lake
When asking questions of the database we may need to know:
1. What is the largest species of fish caught
2. Which member has caught the largest fish
3. Which lake holds the largest fish
4. Which swim produces the best catch
5. What time of day will be best for catching the largest fish

16
17
TEMA 12 - Holiday Cottage Bookings Scenario

The following data model is designed to hold information relating to a holiday cottage bookings. For this
scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Clients
• Cottages
• Bookings
• Cottage Facilities
• Price Bands
• Regions
The Entities are related as follows:
• A Client can Book One or Many Cottages
• A Cottage may have One or Many Bookings made for it
• A Region may contain zero, one or many Cottages
• A Cottage may have zero, one or many Facilities
• A Facility may be associated with zero, one or many Cottages
• A Cottage can have Many Prices associated with it (different prices apply to different times of the
year)
• A Band (Rating applied) can have zero, one or many Cottages
When asking questions of the database we may need to know:
1. Do you have a holiday cottage in a certain region of a particular band (rating)?
2. Is a particular cottage booked at a given date in the year?
3. Do you have any available cottages with a swimming pool (Facility) available?

18
TEMA 13 - Video Rentals Database Scenario

The following data model is designed to hold information relating to a video rentals store. For this scenario
we need to define the following facts:

These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.

The draft facts have been defined as:

The Entities required should include:

• Members
• Rentals
• Video Copies
• Video Titles
• Video Category
• Video Certification

The Entities are related as follows:

• A Member can Rent One or Many Video Copies

• A Video Title may have One or Many Video Copies
• A Video Copy may be Rented by zero, one or many Members
• A Video Title can have only one Certification associated with it

When asking questions of the database we may need to know:

1. Do we currently have any overdue video rentals?

2. Do we have any videos in a certain certification available to rent?

19
TEMA 14 - Customers, Product and Orders scenario

The following data model is designed to hold information relating to Customers Ordering Products. For
this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Customers
• Orders
• OrderLines
• Products
• Suppliers
The Entities are related as follows:
• An Customer can have One or Many Orders
• An Order can contain One or Many Products (OrderLines)
• A Product can be associated with One or Many Orders
• A Supplier can supply One or Many Products
The design allows a Customer to place zero, one or many Orders. An Order can be for one or many
Products, and this Product can be associated with zero, one or many Orders (the reason for the
Link_OrderProduct table)
When asking questions of the database we may need to know:
1. Which Products have been Ordered by a Customer
2. What date/time was a particular Order dispatched
3. How many open Orders do we have in the system
4. What is the Total Order Cost for a certain Order
5. Which Supplier supplies a particular Product
6. How many of a certain Product do we have in stock
7. What is the mark-up on a certain Product

20
TEMA 15 - Employees and Projects Scenario

The following data model is designed to hold information relating to Employees working on company
Projects. For this scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Employees
• Projects
• Departments
The Entities are related as follows:
• An Employee can work on Many Projects
• A Project can have Many Employees associated with it
• A Department can have Many Employees
• An Employee can only work in One Department
The design allows recording of how long an Employee has spent on a given project by including
Work_Date and Hours in the LINK table that is supplied to break up the Many-To-Many relationship
between Employees and Projects.
When asking questions of the database we may need to know:
1. Which Employees are working on a certain Project
2. How many Hours have been spent on a certain Project
3. How many active Projects are currently being worked upon

21
TEMA 16 - Book Collection Scenario

The following data model is designed to hold information relating to a personal book collection. For this
scenario we need to define the following facts:
These facts define the requirements which the Database must meet and should be agreed between the
Database User and the Database Designer prior to physical creation.
The draft facts have been defined as:
The Entities required should include:
• Authors
• Books
• Book Formats
• Book Categories
• Publishers
The Entities are related as follows:
• An Author can write many Books
• A Book can have many Authors
• A Book Category can have many Books
• A Book can have many Categories associated with it
• A Book Format can have many Books
• A Publisher can publish many Books
When asking questions of the database we may need to know:
1. Do you have any Books by Jilly Cooper
2. Do you have any Books in the Sporting Category
22
3. Do you have the Hardback edition of Riders

23