designing inheriting entities

Dear All,
our customer has 3 kinds of entites
the first one is the ApplicationCenter where students can register to
exams...
and there are types of app centers like University offices, high schools
etc.. these types goes to another table..
and finally each type has its own instances like University one ,
university2 , univ3 etc. which means there are several more tables Like
universities , highschools , examCenters etc...
the requirement is to have ADD/Edit/Delete screens of all ApplicationCenters
of the customer..
the listing of the centers and their info is straightforward however when it
is time to edit many entities needs to be updated at the same time
.........
i am trying to figure out a table design where i can build sort of
inheriting entities..
any clue?
best regards..
emre dincer
Emre DNER wrote:
> Dear All,
> our customer has 3 kinds of entites
> the first one is the ApplicationCenter where students can register to
> exams...
> and there are types of app centers like University offices, high schools
> etc.. these types goes to another table..
> and finally each type has its own instances like University one ,
> university2 , univ3 etc. which means there are several more tables Like
> universities , highschools , examCenters etc...
> the requirement is to have ADD/Edit/Delete screens of all ApplicationCenters
> of the customer..
> the listing of the centers and their info is straightforward however when it
> is time to edit many entities needs to be updated at the same time
> ........
> i am trying to figure out a table design where i can build sort of
> inheriting entities..
> any clue?
> best regards..
> emre dincer
It is possible to ensure that each common attribute appears only in
one place in the hierarchy for each type of entity. Therefore the
problem of updating the same attribute in multiple places won't arise.
Fifth Normal Form and the Principle of Orthogonal Design are two
principles that will help you achieve a good model. Google for them if
you aren't already familiar with them.
David Portas

designing inheriting entities

Dear All,
our customer has 3 kinds of entites
the first one is the ApplicationCenter where students can register to
exams...
and there are types of app centers like university offices, high schools
etc.. these types goes to another table..
and finally each type has its own instances like university one ,
university2 , univ3 etc. which means there are several more tables Like
universities , highschools , examCenters etc...
the requirement is to have ADD/Edit/Delete screens of all ApplicationCenters
of the customer..
the listing of the centers and their info is straightforward however when it
is time to edit many entities needs to be updated at the same time
........
i am trying to figure out a table design where i can build sort of
inheriting entities..
any clue?
best regards..
emre dincerEmre D=DDN=C7ER wrote:
> Dear All,
> our customer has 3 kinds of entites
> the first one is the ApplicationCenter where students can register to
> exams...
> and there are types of app centers like university offices, high schools
> etc.. these types goes to another table..
> and finally each type has its own instances like university one ,
> university2 , univ3 etc. which means there are several more tables Like
> universities , highschools , examCenters etc...
> the requirement is to have ADD/Edit/Delete screens of all ApplicationCente=[/vbcol
]
rs[vbcol=seagreen]
> of the customer..
> the listing of the centers and their info is straightforward however when =[/vbcol
]
it[vbcol=seagreen]
> is time to edit many entities needs to be updated at the same time
> ........
> i am trying to figure out a table design where i can build sort of
> inheriting entities..
> any clue?
> best regards..
> emre dincer
It is possible to ensure that each common attribute appears only in
one place in the hierarchy for each type of entity. Therefore the
problem of updating the same attribute in multiple places won't arise.
Fifth Normal Form and the Principle of Orthogonal Design are two
principles that will help you achieve a good model. Google for them if
you aren't already familiar with them.
David Portas

designing inheriting entities

Dear All,
our customer has 3 kinds of entites
the first one is the ApplicationCenter where students can register to
exams...
and there are types of app centers like University offices, high schools
etc.. these types goes to another table..
and finally each type has its own instances like University one ,
university2 , univ3 etc. which means there are several more tables Like
universities , highschools , examCenters etc...
the requirement is to have ADD/Edit/Delete screens of all ApplicationCenters
of the customer..
the listing of the centers and their info is straightforward however when it
is time to edit many entities needs to be updated at the same time
........
i am trying to figure out a table design where i can build sort of
inheriting entities..
any clue?
best regards..
emre dincerEmre D=DDN=C7ER wrote:
> Dear All,
> our customer has 3 kinds of entites
> the first one is the ApplicationCenter where students can register to
> exams...
> and there are types of app centers like University offices, high schools
> etc.. these types goes to another table..
> and finally each type has its own instances like University one ,
> university2 , univ3 etc. which means there are several more tables Like
> universities , highschools , examCenters etc...
> the requirement is to have ADD/Edit/Delete screens of all ApplicationCente=rs
> of the customer..
> the listing of the centers and their info is straightforward however when =it
> is time to edit many entities needs to be updated at the same time
> ........
> i am trying to figure out a table design where i can build sort of
> inheriting entities..
> any clue?
> best regards..
> emre dincer
It is possible to ensure that each common attribute appears only in
one place in the hierarchy for each type of entity. Therefore the
problem of updating the same attribute in multiple places won't arise.
Fifth Normal Form and the Principle of Orthogonal Design are two
principles that will help you achieve a good model. Google for them if
you aren't already familiar with them.
--
David Portas

Design Question

I am in the design phase of a relational database using OO methods...I have three groups of people that I want to track...1. Students 2. Parents 3. Adult Volunteers...

I have started with a table called people where I have attributes that are common to all three groups of people...then I have a students table and volunteer table that have attributes common only to a student or volunteer...the key in these tables is also the FK of the people table. I think this is proper design.

Here is my question:

There is a many-many relationship with parents and students. A third junction table is needed I know but how is this accomplished with subtype tables...would I create the juntion between parents table and Students table or between parents table and people table?

Any suggestion would be appreciated. Maybe this is all wrong and someone has a better solution...thanks

Tonypost what the current fields are in each table and the relationships between them.|||You have identified that Students, Parents and Volunteers are all types of people, so you have created a People table with a primary key (PeopleID). In the Student and Voluteer tables there are keys that contain PeopleID.

The task is to show the relationship between a student and its parents. Students and Parents are all sub-types of People. What you are trying to define is a relationship from one person to another, so the design should link a record from the People table to another record in the People table.

The Parent table will have a PeopleID column that represents the student and a second column with a renamed PeopleID to represent the ID of the parent. You can then add any other columns that contain parent data. The primary key will be a compound key based on the first two columns.

Referencing column 1 will list all the people who are the parents of Student A. Referencing column 2 will list all the students of parent B.

By linking people records in this way you can also represent the relationship where a parent is also a student.

As the table can be used to represent any relationship between two people records, you may want to check if any other relationships need to be represented (Student A is the brother/sister of Student B etc.) If so, you could add a RelationshipID column to the table, add it to the primary key and change the name of the table.

Whether this is the best solution for you depends on all of your requirements. Hope you found this useful.

design of a process

I'm going to design a web page for students parking permit application.I'm new to asp.net, I have a process in mind doing it like this:

The form asks student to choose a permit type, then fill in applicant info, like name, grade, vehicle info, student may have 2 vehicles, and payment method, check or credit card,

I plan to create 3 tables like tblPermit, tblapplicant, tblVehicle.

After the students fill in the form, click submit button, I pass the values and call a stored procedure, some thing like this.Dim CmdAsNew Data.SqlClient.SqlCommand(MySQL, MyConn)

Cmd.CommandType = Data.CommandType.StoredProcedure

Then in the stored proceudre, I will do :

Begin

insert into Permit table, then get permitID, by using something like this:

Select @.PermitID=@.@.Identity

Then insert into Student table,then use

Select @.StudentID=@.@.Identity

Then insert into vehicle table.

All the above 3 processes I put it in begin, end--So that they will not messed up with other applicants data.

I think begin...end is one transaction.

SO am I doing correctly this way? Thanks

Begin...End doesn't signify a transaction, it signifies a code block. The idea is basically correct, but use SELECT @.PermitID=SCOPE_IDENTITY() instead. You should also wrap the whole thing in a transaction to be safe.

|||

So shall I use something like this:

AS
Begin

Begin transaction
Set NoCount on
DECLARE @.PermitID INT
Insert table............

Commit Transaction

End

Can I use the begin transaction ...commit transaction in Begin ......end, or no need of begin..end.

Thanks