The primary Entities are going to be: 1 Room: - RoomID, Room Num, type, number of beds, etc.

2 Calendar: - Date, Status (Open or Closed) 3 Client: - ClientID, Client name, address, tel, email etc 4 RoomStatus: RoomStatusID, RoomStatus (Available, Booked, Maintenance...) 5 RoomDate: RoomDateID, RoomID, Date, RoomStatusID, ClientBookingID This entity is used to show room availability, help with planning maintenance, and show rooms booked - booked rooms carry the booking reference (ClientBookingID) 6 ClientBooking: ClientBookingID, ClientID, BookingDate, DepositPaid, Amount($), AmountPaid Primary Relationships will include: All One-Many 1-5 2-5 4-5 3-6 6-5

If we were to show the ConsistsOf-MadeUpOf relationship between Bookings and BookinLog: Wed have to have a RoomNumber-StartDate pair of attributes in BookingLog corresponding to the Bookings key Better to have an automatic key for Bookings not necessary for Booking Log Also, we can remove the CustomerID attribute from Booking Log as it can be inferred when we add Booking Code

Lesson 2.1: Generate a physical data model

Generate a physical data model from the logical data model you already created. Examine and add properties to your physical data model. To generate a physical data model from an ER diagram created in the previous lessons:

1. In the Tutorial encyclopedia, under the Data Modeling tab of the Explorer, expand Models > Hotel Reservation System > Diagrams > Entity Relation. Doubleclick Hotel Check-In, or drag it onto diagram workspace. 2. Select Dictionary > Create Data Model > Physical Data Model > . The Create Physical Data Model Diagram dialog opens. 3. Diagram Name: leave the default, which is the name of the ER diagram. 4. Super/Sub Resolution Method

Within this dialog, you specify how you want to map super-sub relationships in the logical ER diagram to physical tablesthe concept of super-sub relationships and the inheritance from the super to the sub does not exist in physical modeling. The choices are:

o Separate Tables: creates a separate physical table for every entity in a super-sub grouping. Attributes for each entity are mapped to columns in
each respective table.

o Merge Supertype to Subtype: creates tables for all sub-entities, does not create a table for the super-entity. Each table created for a sub-entity
contains columns mapped from the attributes of the corresponding sub-entity, plus attributes 'handed down' from the super-entity.

o Merge Subtype to Supertype: creates one table for the whole super-sub entity structure. Attributes from all super- and sub-entities are mapped to
columns in the one table created.

o Prompt for Each Super/Sub Group: System Architect will prompt you with a dialog enabling you to choose the mapping for each Super/Sub group
as the transformation of logical to physical diagram takes place.

o There are no super-sub groups in this data model, so you can leave the default at "Separate tables."
5. Resolve Non-specific relations: If any of the relationship lines between entities are non-specific, System Architect will convert them to constraints in the physical data model. Most DBMS do not accept non-specific constraints. 6. Name Mapping: you can choose how the case of names of Tables, Indexes, Constraints and Columns are mapped from the names of their corresponding Entities, Attributes, Relationships and Indexes. You can choose whether to replace non-standard characters, such as spaces, with underscores. Most DBMS do not accept non-standard characters.

Leave the default at Retain Case and toggle on "replace non-standard characters" for all four check-boxes. 7. Click OK. Rational System Architect will begin the mapping. A running log detailing the mapping will appear on the screen, under the title Generate Physical Data Model. 8. System Architect presents you with a dialog in which you must select the Model, DBMS and Database Name for the physical diagram. Leave Model at its default, Hotel Reservation System. Enter HOTEL in Database Name. From the DBMS drop-down list choose SQL Server 2000. Click OK.

Note: The number of DBMS's listed depends on the DBMS's chosen in the System Architect Property Configuration dialog. The list of DBMS's can be changed at any time during a project by selecting Tools > Customize Method Support > Encyclopedia Configuration, selecting the DBMS you want from the Target Databases list, and reopening your encyclopedia. 9. The physical diagram is created, and the Generate Physical Data Model running log dialog completes. The last line of the log is "Physical diagram created." 10. Close the running log by clicking x in its upper right-hand corner. Note: If the physical diagram created is off to the right on the diagram workspace, and not visible on the screen, select View > Zoom > Used Area to view the entire physical diagram.

If you want to move all the symbols, select Edit > Select All. Drag the group of objects where you want them. 11. Select File > Save Diagram to save the diagram.

Examine the physical table

The table in the physical model represents the table that will be implemented in the database. It contains specification of the table's columns, indexes, and physical properties such as Filegroup. Physical properties are DBMS-specific.

To examine a table in your physical diagram: 1. Select the table Guest. Open its definition by double-clicking on it or by clicking on it with the right mouse button, and selecting Edit. 2. Notice in the Column grid of the table's definition dialog, that the columns have been mapped over from corresponding attributes in the corresponding entity of the logical data model. Note: Remember that column names default to the name of the underlying data element, and not to the name of the attribute.

3. The generic data types in the logical model have been mapped to SQL Server-specific types. 4. All data structures have now been expanded into relevant columns in the physical table.

In the logical model, we added the data structure Address to the logical entity for Guest. The data structure was composed of data elements Street, Town and District. Notice that Guest now has columns with those names. 5. A new primary key, number, has been migrated from the parent table Room as a foreign key. Both the PK and FK cells are checked for each column. 6. Column names have been derived from the data element name in the logical entity.

In the logical entity, the name of the logical data element was Guest Number (with an embedded space), and the attribute name was Guest#. The column is named Guest_Number

Select Guest_Number by putting your cursor in its name box and clicking the Define button at the bottom of the Column grid. You open the full definition dialog for this column.

Select the Source & Key Info. tab. In this tab, you can see the source attribute and data element for this column. It is read-only, but if you click the Define button you can view all the information on either source item. 7. Click OK or Cancel to close all dialogs.

Add physical properties unique to SQL server

The physical properties of a table vary depending on the target DBMS. For example, in SQL Server common properties include Filegroup and Filespec; in Oracle, you will find tablespace and datafile. Objects like triggers and stored procedures are common to almost all DBMS. Before you can supply a Filegroup, you need to create the Filespecs: 1. Within Rational System Architect's Explorer highlight the Definitions branch and select New from the floating menu.

2. In the Select new type for all Methods dialog, scroll down and double click on the SQL Server Filespec. 3. Enter System 12345 as the name of the SQL Filespec. 4. Enter the FileName as c :\Program Files\\Microsoft SQL Server\\data\\Hotel_spec.mdf. Note that the filename must be entered with double back-slashes. 5. Specify the Model name by selecting the Choices button and drag in the Hotel Reservations System. 6. Specify the Database Name by selecting the Choices button and drag in the Physical Database called HOTEL. 7. Press OK.

8. Enter the values as pictured below. If any values for properties are not entered, they default to the SQL Server default value.

9. Open the Guest table definition (right-mouse click and select Edit or double-click on it). 10. Click on OK. 11. Using the same method as above create another SQL Sever Filespec named System123Log. 12. Enter the FileName as c:\\Program Files\\Microsoft SQL Server\\data\\Hotel_log.mdf. Note that the filename must be entered with double back-slashes. 13. Specify the Model name by selecting the choices button and drag in the Hotel Reservations System. 14. Specify the Database Name by selecting the Choices button and drag in the Physical Database called HOTEL. 15. Press OK.

16. In the Filespec dialogue enter the values as pictured below. Toggle on the Log File check box. Click on OK.

17. Open the Guest table definition (right-mouse click and select Edit or double-click on it). 18. Click on the Triggers & Table Filegroup tab in the table Guest. 19. In the Filegroup textbox enter HotelSystem and click on the Define button. 20. In SQL Server, filegroups are defined by filespecs. 21. In the FileSpec list box click on the Choices button. The Select and Drag dialog gives you a list of the SQL Server Filespecs that we created previously. 22. Select and drag the System 123456 and System 123Log in the list box. (Items are selected and dragged into the list box by selecting them, holding your left mouse button down, and dragging them into the top of the list, then releasing them so that they are added to the list.)

23. In the SQL Server Filegroup dialogue box, click on OK. 24. Click on OK to close the table definition dialogue.

Lesson checkpoint Lesson 2.2: Model constraints between tables

Model a constraint in your physical data model to demonstrate the constraints between a guest of a hotel, and their vehicle. Enter the room number of a guest as the role name. Respond to error messages. A constraint in the physical data model is the equivalent of a relationship line in an ER diagram: it models the relationships between tables just as the relationship line models the relationships between entities. The constraint can be specified only as identifying or non-identifying. An identifying constraint is an instance of the child table that can only exist if there is a parent table. The primary keys in the parent table will be both primary and foreign keys in the child table. A non-identifying constraint indicates that an instance of the child table can exist even without a parent table. The foreign keys may be non-key columns in the child table. To model a constraint: 1. In the Tutorial encyclopedia, open the definition dialog for the Guest-to-Vehicle constraint line between Guest and Vehicle. 2. Notice that you can change this line to identifying or non-identifying (child optional) in the dialog. 3. Click on the Foreign Keys tab. Notice the role name Guest for the primary key Guest_Number. You entered this value on the relationship in the logical model. You also entered the constraint name there. 4. Click OK to close the dialog. 5. Notice that the primary key of Guest (Guest_Number with the role name Guest) is both primary and foreign key in Vehicle, the child of an identifying relationship. But the primary key of Guest is only a foreign key in Reservation, the child of a non-identifying relationship.

Enter Role Names

A role name is the name of a column in its role as a foreign key in a child table. It is a constraint property. To enter a role name for Room Number: 1. Click on the constraint belongs_to between Room and Guest in the physical model Hotel Check-In. 2. Click on the Foreign Keys tab. 3. Enter the role name Room_Number in the role name column for the column number. 4. Click on OK. 5. From the menu bar, click on Dictionary, Update FKs. Your diagram should now look like the following figure. Notice that the foreign key number in the Reservation table has also changed.

Enter trigger codes and messages

Designate the code and message that is displayed when you make an error on insertion, update and deletion of a record in the child table. To enter trigger codes and messages to respond to an error message: 1. Click on the constraint Guest-to-Vehicle between Guest and Vehicle in the physical model Hotel Check-In. 2. Click on the Error Codes/Messages tab. 3. Error codes are a numeric value, starting at 20001. In the Parent Delete Code box, enter the number 44321. 4. The message can be any text you want, to a maximum length of 255 characters. Enter this message "You cannot delete this Guest because it still has corresponding Vehicles." 5. Enter in the Child Insert Code box the number 51234. In the corresponding Message box, enter : "You cannot insert a Vehicle without a valid Guest Number." The dialogue should now look like the picture below.

Hotelier - Hotel Management System is an ideal software solution for Hospitality Industry that can be used at hotels, motels, inns, resorts, lodges, hostel, military guest houses, ranch, suites, apartments, medical centres and bed, breakfast operations. Our product Hotelier Hotel Management System is a comprehensive software suite consisting of integrated modules for various aspects of hotel management. The software is often referred to as Property Management System in the Hotel industry. Hotelier includes all the features required in a Hotel Management Software, Hotel Reservation Software, Hotel Reception Software (Front Office), Call Accounting, Hotel Point of Sales (Restaurant, Bar, Room Service, House Keeping or any other outlet), Inventory Management System and Hotel accounting software. In our lodging software all modules are tightly integrated and all hotel programs are included in one price, meaning all modules are included at no additional cost regardless of your hotel size. Our Motel management software is developed for Microsoft Windows operating system using latest software developing techniques. Hotelier is hospitality software designed for full service luxury inns, bed, breakfasts, and resorts. It emphasizes the highest level of individual guest services through our comprehensive features seamlessly integrating rooms, dining, and retail, with information contained in reservations till back office general ledger.

6. Click on OK to close the dialogue and save the values. < Previous | Next >

Hotelier - Hotel Management System is an ideal software solution for Hospitality Industry that can be used at hotels, motels, inns, resorts, lodges, hostel, military guest houses, ranch, suites, apartments, medical centres and bed, breakfast operations. Our product Hotelier Hotel Management System is a comprehensive software suite consisting of integrated modules for various aspects of hotel management. The software is often referred to as Property Management System in the Hotel industry. Hotelier includes all the features required in a Hotel Management Software, Hotel Reservation Software, Hotel Reception Software (Front Office), Call Accounting, Hotel Point of Sales (Restaurant, Bar, Room Service, House Keeping or any other outlet), Inventory Management System and Hotel accounting software. In our lodging software all modules are tightly integrated and all hotel programs are included in one price, meaning all modules are included at no additional cost regardless of your hotel size. Our Motel management software is developed for Microsoft Windows operating system using latest software developing techniques.

Hotelier is hospitality software designed for full service luxury inns, bed, breakfasts, and resorts. It emphasizes the highest level of individual guest services through our comprehensive features seamlessly integrating rooms, dining, and retail, with information contained in reservations till back office general ledger.

DBMS
Data Base Management System an Introduction and history

editor: Cornelis Robat & Tim Vick (1) part 1

Collections
With Netfirms as your registrar, hosting

Canadian domain names has never

been easier. Buy and register domain names cheap!
20110606

Related Articles Introduction to software history

Related Resources

Everywhere in the world there are collectors. And you may take it from me; there are A LOT OF THEM. It is very human to have something you collect. There is nothing abnormal to it, rest assured. In our life, in the kitchen, or in our desk drawer at home, there is bound to be some sort of collection. So let's presume you have a collection; if not you, your partner, friend, or family member will collect something. You, he or she collects books, computers, pictures, coins, baseball caps, coasters, addresses, organs, cars, recipes, pots and pans, a collection of collectibles, or whatever collection that seems to belong together. All the money in your bank account is a collection, too. And the antique cutlery in your mom's cupboard is a collection as well. So if the 'objects' have some connection to one another, or they belong together in some way, it is a collection. Lets assume in the years past and to come that this collection of yours has grown dramatically. Just like the picture collection of this site. It became huge! In a few years you will forget you had this special coin or recipe in your box (and another box, and another box). You will have undoubtedly some duplication in your collection. So here is a question: how do you find this little precious thing that you are not sure you have? Answer: you need some sort of organization in your collection, a registration! Registering a collection makes the registration of it a "Database". Another case: Have you ever gone to a hotel, airline, or box office at the cinema and you had a reservation but your name disappeared into never-never land? Well it happened to me more than once. And did you start to wonder how that could be? You even ordered via the Internet! Couldn't be more sure, you thought... wrong!

In 99% of all cases your name is there. Your ticket or room key will be handed over or the bus ticket is there at the counter for you. Everything goes well, normally. The way they keep order in this is that businesses (airlines, cinemas, hotels) also collect something: your name, address, age, telephone number, gender, name of your partner, age of your partner, are you a vegetarian, are you Singhalese, American ...

a collection of people

All this information about you is called data and is stored electronically into a document or more precisely: a file. If this file is just a few pages long, there will be no problem finding your information.

But, say a hotel collects data from a lot of people: past, present and future guests. The hotel stores preferences: smoking, non-smoking, what ever. In our simple case study our hotel is famous for its animal correctness, so why not collect the name of the guest's pet, too! Now this will become a lot of "data" that will grow and grow and grow. And again here is the question: how do you find your way in all this information. Did the receptionist write all this data on a piece of paper?

piece of scrap paper

Disaster! Maybe the reception desk is organized and the receptionist puts all the names on stock cards? And puts them in alphabetical order?

stock card

With a lot of these cards, one or more are bound to get misplaced.

Our study case: Hotel Bincker's In the last few years Hotel Bincker's has grown from a small village hostel into a medium sized business hotel in a rapidly growing small silicon village town. And the desk has no time to keep track of all information needed to take care of its guests in a proper way. "We are a hotel not an airline!" is vaguely muttered by the manager

after he lost your name again, did not cross off the room on his blackboard and booked the same room twice. But after management communicated its concern with losing clients, the manager promises to clean up his act. Some weeks later when you show up at Hotel Bincker's desk the manager will finger through his agenda which is ordered by date and he will find your reservation. This method works well for a small hotel. Guests are coming back and the hotel's business is profitable again.

Hotel Bincker''s agenda and room reservation "database"

But after some years, Hotel Bincker's has grown again. Now it is a larger hotel with some 100 rooms and the manager is still using an agenda for each floor, and then history repeats: your name is lost. The manager needs

many minutes to find what room is available. It is obvious that any (paper) agenda would be too small to schedule over 100 rooms. Hotel Bincker's is losing its clientele again. This time the manager cannot rescue the situation with a simple agenda anymore. He starts complaining to his wife and kids, who start to show him their electronic agendas with all their gadgetry. Now that's an idea! Still having his old faithful agenda and keeping track of reservations electronically. But within a day running the hotel's administration on a small PDA proves to be a useless exercise. The solution is found but something bigger is needed. The need, however, for an electronic version of a combined agenda and guest list is confirmed by the managers little test case. So the managers daughter Lisa starts browsing the Internet and finds out that a hotel reservation system would be the answer to her dad's problem. Together they start contacting companies that sell or create reservation systems. But for a small hotel like Bincker's with its specific services, no off-the-shelf system seems to be available or affordable. The step from paper agenda to a full blown computerized hotel reservation system is too big for the hotel's management and does not match with the hotel's business culture. But Lisa learned a lot while browsing the Internet and she starts explaining to her dad how a system like that would work and what such a system can do for his business. Above all, she explained how to plan such a project. Here is how Lisa started to explain to her dad how to proceed: Imagine that a hotel is nothing else than a collection of rooms and, like any collection, we need to have some form of registration. Keeping track of rooms in an orderly way can be with a list:

Rooms

20

10:11

DEC Name First Gender Out Room 101 102 103 104 206 208 302 303 Smoker N N Y Y N N Y N

A guest can be entered in that list when he or she arrives at the hotel:

Occupancy list

20 Dec

10:11

Name Dijkstra Romero Rubnes Voloute Xantia Zeppelin

First Jan Paolo Jetro Maria Citon Ger

Gender M M M F F M

Out Y Y Y N N N

Room 101 104 201 299 300 301

Smoker N N Y Y Y Y

Guests and their rooms

In case we are out of vacancies we can contact our guests via our address list:

Names and Addresses

Name First Phone 31 44 Dijkstra Jan 345 3666 Romero Paolo 123 M Pietro N N M Y N Gender Pet Vegetarian Smoker

4523 3509 101 Rubnes Jetro 4403 2226 404 Voloute Maria 2396 2350 F N Y M Vlato N Y

Lisa continues: The above examples show you how a simple list of rooms and persons gets rid of the misplaced papers. Names and rooms are shown in a particular order, in this case alphabetically, so you can quickly find what you are looking for. These examples are already a small database, see? But remember a database can have any physical form: paper, on a blackboard, an electronic file, or even some tally sticks. (a very early form of some kind of registration in 1310)

tally sticks

The lists we have here can be put on a computer in a word processor document or some tabular sheet like a spreadsheet. These are called files. It is possible to combine those two in any way, already a sort of database. The difference between a database and a file is that there is something extra to it. A database must contain a method, amongst other things, to look up something. Comparable to the databases used by search engines like Google, Alta Vista, or Yahoo that we use to find companies which could sell us a reservation system. The Internet is also some kind of database. And all this information is managed by a database management system, hence DBMS.

Case study: Hotel Bincker Our biggest problem is to find rooms that are vacant and the ones that are occupied, says Lisa. Below I have drawn an example listing for vacancies that can be called with one click of a button:

Vacancies
Name First Gender Out

01 DEC Room 102 106

10:11 Smoker N N

101 103 202 205 302 303

Y Y N N Y N

Here is part of the rooms list with guests who reserved a room for the 20th of December

Reservations
Name Dijkstra Romero Rubnes Voloute First Jan Paolo Jetro Maria Gender M M M F Out Y Y Y N

20 DEC Room 104 108 202 292

10:11 Smoker N N Y Y

Xantia Zeppelin

Citon Ger

F M

N N

303 301

Y Y

And here is a part of the address list of persons who made reservations or have been guests at our hotel.
Name Dijkstra First Jan Address 14 Pinkerton lane Deloit, 1234DE Delaware USA Romero Paolo Plz de 5 Mayo 123 4325-23 Roma Italy Rubnes Jetro 123 Pole Ye 101 M Vlato N N No 123 4523 3509 M Pietro N N Notes Yes Phone 31 44 345 3666 Gender M Pet Vegetarian Y Smoker N

23 Deliver to mailoffice San Remaro Trinidad Voloute Maria

4403 2226

12 rue de la liberte Auxerre 120394 France

No

404 2396 2350

When our desk manager wants to have a quick view when a room becomes available, or for that matter occupied rooms, he calls up his agenda in the form of a chart:
Roo m S U 2 0 M O 2 1 T U 2 2 W E 2 3 T H 2 4 F R 2 5 S A 2 6 S U 2 7 M O 2 8 T U 2 9 W E 3 0 T H 3 1 F R 0 1 S A 0 2

101 102 103 104 105 201 202 206 207

This chart is color coded, blue is a guest, green is available, purple are reservations, yellow is a national holiday or other special day; mostly meaning prices go up. When our front desk manager wants more specifics he can open a sub window to search for a room (in all possible combinations: adjacent rooms, smoke free, etc.) Or use the more advanced form of a floor plan:

Our front desk manager will have an instant overview of all available rooms and their configuration. That, concludes Lisa, is all we need. Not a complicated system like the Hilton has, but one that offers you the information you need with one click of a button. And one where we can put in the information we have on our guests habits and likes or dislikes. So, asks her dad, how would we go ahead? What do we need? A scientist? It must be a system that we can maintain by ourselves with no need for expensive consultants with little knowledge of our business. And Lisa answers: You know, dad; we just happen to have an assignment in our class that just covers your need. Instantly a broad grin plays on Dads lips. OK, he says, let's see if we can be of mutual benefit to each other.

So now you have some idea of how most automation projects start: from a certain need and/or a fear of losing business. Continue to the next chapter where I will introduce some methods and techniques used to analyze information.

DBMS
Data Base Management System an Introduction and history

editor: Cornelis Robat & Tim Vick (1) part 2

Related Articles

Introduction to software history

Related Resources

Introduction (continued)
Assignment:
Your goal as a software engineer is to design a user friendly, solid and above all reliable database system.

The previous examples served to give you an idea of the need to organize information. This part will show you some examples of what a software engineer uses to create a design of a database system for our Bincker's Hotel example. The first step in your assignment is to get a picture of how this hotel business actually runs. This process is called: Analysis. There are various methods and techniques to perform such an analysis and without getting too theoretical and since this is just a quick reference text lets get our hands dirty.

What stages do we need to go through to get to a fully functional system? An example is shown below.

In this chapter we constrict ourselves to the analysis part of the above diagram. There are various types of analysis:

Information Analysis; analysis of our business's processes Functional Analysis; analysis or functionality of our processes Technical Analysis; analysis of the components of our functionalities Data analysis

What all this means is explained below.

First phase: Information Analysis

Information Analysis first of all creates an image on how a business or organization is put together and what processes are of importance. Our project primarily deals with people and how they do their jobs in keeping a hotel running and afloat. So what do they do when receiving a guest, making reservations, giving information to people, selling and serving meals, snacks and drinks and so on? In other words Bincker's hotel business has to be dissected into separate processes for us to understand how this all fits together:

Receiving and registering guests Register reservations Responding to inquiries, providing information to guests Sell meals, snacks, drinks Maintenance, cleaning rooms, floors,

linen... Rostering employees Receive money for rendered services Pay salaries and bills, possibly some bribes and other expenses ...

Mind you we only deal with the large chunks here. Each chunk is called a process. And as many roads lead to Rome, there are of course several ways to put up this (primary) process lists but for now it'll do fine. Next step after identifying primary processes is to break down all primary processes into smaller processes. Until there is no part that can be called a process because everything has been broken down into basic actions. Now break down a primary process into a smaller process.

Receiving and registering guests

Welcome guest Ask guest his wanting (a room)

Check if guest has a reservation (ask name) If no reservation check for available rooms ...

Can this be broken down into even smaller processes?

Check for available rooms Call up vacancy rooms list Ask guest's preferences If room available as desired claim room

If OK book room Ask guest's other particulars (address, city etc.) ...

Into even smaller processes?

Ask guest's other particulars Enter last name, first name into form Enter address, city, country into form ...

You see the above examples show processes that are broken down into actions until there are no processes that can be identified as autonomous processes any more. In fact actions are the atoms of our processes. Atoms can also be broken down into smaller parts, but the question is if this has any added value in the cadre of our information analysis. Braking up atoms into smaller parts is part of the functional design, see introduction to program development for more details.

Below you'll see some quick and big steps through this analysis process.

At first all elementary primary business processes are identified. Shown here are the primary processes listed at random order.

Then draw a relational schematic of how all these processes are connected together.

Note:

processes are not necessarily in correct order or connection, this graph just serves as an example Important is to determine how processes are connected together. This is done by connecting the processes with lines is such a way that is is shown how one process serves as input or output for one or more other processes.

Like a guest serves as input for the financial system (paying for the room) but also a input for the rooms proces. The finance process churns out money that is input for for the suppliers process (paying bills).

NEW GRAPH .

Normally you continue to describe the processes.

Some elements you would like to describe

A precise description of the process itself and its role in the organization Relationships with internal and external processes The input a process needs to do its function: resources, conditions.

After you have identified all processes you might continue to determine the elements a process contains. For example the 'Guest' process contains a person. This person might have a pet. There are notes on this person and his pet, the guests habits and dislikes, preferences (e.g. preferred airline), trips he or she or they booked, what means of payment he/she uses, his/her business address, home address, etc, etc.

So let us describe a basic guest (object).

A guest could be described as

follows:

Name Address City Country Phone number email

There are many more properties one could name to describe a guest (called: object) below is a small sample of that.
A guest can be much more than just an address

What makes Bincker's hotel so special is that management keeps track of its guests birthday, habits, likes, preferred foods, hobbies, trips he or she organized, preference of rooms, the way the rooms smells, anything that can enhance the guests well being and feeling at home. The hotel personnel take

special care of their guests in a way only 'above' five star hotels do. So here are some more properties of our 'object': guest

Birthday Married Gender Favorite dishes and drinks Dislikes Likes Smoking Pet Important habits Transport MeansOfCommunication MeansOfPayment Trips Wake-up-call Preferred airline Notes

Et cetera. But the hotel does not only have guests, it also has relationships with suppliers and personnel and other types of relations. So let us call this list of addresses our relations database (the address list). All objects together of our relation database comprise our Relation Information System (RIS).

And how will you be sure you covered everything?

We will use the mind mapping technique, which is often used when analyzing objects and their relationships. Shown as an example here is part of the mind map the project (thocp.net) is using to cover all subjects at the games section.

Important to this way of displaying relationships is that you put your focus to the object what your business is about: your guests. In the above example that is the project's games section.

Last Updated on July 20, 2005

For suggestions please mail the editors

Footnotes & References

To remind you, these chapters do not serve as a text book on database design, but aims only to give you some insight on how a DBMS is put 1 together and what processes are involve. In a very generic and global way. If you have any suggestions on how to make these pages any better please do not hesitate to contact the editor. 2 3