I am thinking about the database schema for a road map and thinking about the best possible model.I have following queries in my mind that need to be tackled like
Do streets s1 and s2 intersect?
Get all streets adjacent to point of interest p.
OR
Get the distance between entrance e1 and exit e2 on highway h.
Get the shortest route from intersection i1 to intersection i2.
I thought the table names should
roads and streets, including highways
governmental regions: states, counties, and local municipalities of cities, towns, villages
I have strong expertise in Database modeling, but this is first time I am creating a schema like this, Any help in this regard
As per SO rules, OP have to show some effort , I have seen some similar questions thats why I am asking for help in schema.
You need to have nodes and edges - for inner solving your tasks. (short way and so on)
You need the roads and streets and regions you have told about to translate from your inner model to human language. Also, don't forget the point objects: bus stops, crossroads, house entrances, phone booths, shops atd.
So, you need two models and a structure and a set of methods for translation between them.
Inner model:
Table: NODE Table: EDGE
Id Id
place(REGION.Id) Start(Node.Id)
End (Node.Id)
Length
road (ROAD.Id) (to what road belongs)
Outer Model:
Table: ROAD Table: Crossroad Table:REGION
Id point (NODE.Id) Id
Level Id Name
Name Level
Parent (REGION.Id)
You will need to know if roads intersect. The answer to that question should be in your database model.
It is the most important question you can have.
I would say that you need to organize your information around intersections. What road of which type is present at intersection at GIS location (x,y)?
There is only one table for roads, but each road can be of different types. Sometimes can a road be different types of road, yet have the same traffic rules. To get that distinction within the model would I make a distinction between type of road and effective type of road.
A first entrance for a data model is: http://www.osgeo.org/.
EDIT: take a look for instance at this link on that site:
http://live.osgeo.org/en/index.html
There can you download a distribution that enables you to test different open source geospatial software.
This might be exactly what you are looking for:
http://mapguide.osgeo.org/
Related
I have road assets in a GIS layer (spatial table in an Oracle geodatabase).
Roads are split into separate lines/records where they intersect. This is an established business rule that cannot be changed.
Each road has work order records in a related table (in Maximo 7.6.1.1) that pertain to a point along the road.
Scenario:
A new road (#200) has been built that intersects an existing road (#100). Road #100 needs to be split into two separate roads at the intersection of road #200 (this is accomplished using GIS editing tools).
Question:
What are the options for managing the the road IDs and the related work order records?
Here are the options that I can think of:
Option 1:
Decommission the current road (#100) using the status field and create two new roads (#101 and #102).
The work order history will remain associated with the decommissioned road, not the new roads.
The road ID of the decommissioned asset could be stored in a decom_road_id field in the new roads.
Option 2:
Split the current road (#100). Keep the existing road_id for the section on the left-hand side (#100) and create a new road ID for the section on the right-hand side (#101).
The work order history will remain associated with the existing road (#100).
This means that the work order records on the right-hand side of the road will have incorrect road_ids.
Option 3:
Same as option 2, except we correct the road_id of the work orders on the right-hand side (to #101).
I'm working on a comic book database project, and I need to be able to include the various locations within a particular comic issue. There are a couple issues I have to work with:
Locations are more often than not inside other locations (the "Daily
Bugle building" is on "The corner of 39th street and 2nd Avenue" is
in "New York City" is in "New York", etc.)
While the hierarchy of locations is pretty standard
(Universe->Dimension->Galaxy->System->Planet->Continent->Country->State->City->Street->Building->Room),
not all the parent locations are necessarily known for every location
(a comic might involve a named building in an unnamed country in
Africa for instance).
There are a few locations that don't fit into that nice hierarchy but
branch off at some point (for instance, "The Savage Land" is a giant
jungle in Antarctica, so while its parent is a Continent, it is not a
country).
My main goal is to be able to run a search for any location and get all issues that have that location or any locations within that location. A secondary goal is to be able on the administration side of the application to be able to autocomplete full locations (ie I type in a new building for an issue and specify that it is in New York City, and it pulls all "New York City" instances -- yes, there is more than one :P -- in the database and lets me chose the one in Earth-616 or the one in Earth-1610 or I can just add a new New York City under different parent locations). All that front-end stuff I can do and figure out when the time comes, I'm just unsure of the database setup at this point.
Any help would be appreciated!
Update:
After a lot of brainstorming with a couple peers, I think I have come up with a solution that is a bit simpler than the nested model that has been suggested.
The location table would look like this:
ID
Name
Type (enum list of the previously mentioned categories, including an
'other' option)
Uni_ID (ID of the parent universe, null if not applicable)
Dim_ID (ID of the parent Dimension, null if not applicable)
Gal_ID (ID of the parent Galaxy, null if not applicable)
...and so on through all the categories...
Bui_ID (ID of the parent Building, null if not applicable)
So while there are a lot of fields, searching and autocomplete work really easily. All the parents of any given location are right there in the row, all the children of any location can be found with a single query, and as soon as a type is defined for a new location, autocomplete would work easily. At this point, I'm leaning towards this approach instead of the nested model, unless anyone can point out any problems with this setup that I haven't seen.
For hierarchical data, I always prefer using a nested set model to a parent->child (adjacency) model. Look here for a good explanation and example queries. It's a more complicated data model, but it makes querying and searching the data much easier.
I really like what #King Isaac linked earlier about the nested set model. The only arguments I have with what the link said is scalability. If you're defining your lft and rgt boundaries, you have to know how many elements you have, or you have to set arbitrarily large numbers and just hope that you never reach it. I don't know how big this database will be and how many entries you'll have, but it's good to implement a model that doesn't require re-indexing and the such. Here's my modified version
create table #locations (id varchar(100),
name varchar(300),
descriptn varchar(500),
depthLevelId int)
create table #depthLevel(id int,
levelName varchar(300))
***Id level structuring***
10--level 1
100 101-- level 2
1000 1001 1010 1011 --level 3
10000 10001 10010 10011 10100 10101 10110 10111 --level 4
Essentially this makes for super simple queries. The important part is the child id is comprised of the parent id plus whatever random id you want to give it. It doesn't even have to be sequential, just unique. You want everything in the universe?
SELECT *
FROM #locations
WHERE id like '10%'
You want something down the 4th level?
SELECT *
FROM #locations
WHERE id like '10000%'
The id's might get a little long when you get down so many levels but does that really matter when you're writing simple queries? And since it's just a string you can have a very large amount of expandability without ever having to reindex.
How could the following database schema be drawn using E/R diagrams? (A sketch or final image would be helpful). I would also appreciate if you could guide me to a easy-to-understand tutorial on entity-relationships so I could learn how to draw them on paper first.
A CD has a title, a year of production and a CD type. (CD type could be anything: mini-CD, CD-R, CD-RW, DVD-R, DVD-RW...)
A CD usually has multiple songs on different tracks. Each song has a name, an artist and a track number. Entity set Song is considered to be weak and needs support from entity set CD.
A CD is produced by a producer which has a name and an address.
A CD may be supplied by multiple suppliers, each has a name and an address.
A customer may rent multiple CDs. Customer information such as Social Security Number (SSN), name, telephone needs to be recorded. The date and period of renting (in days) should also be recorded.
A customer may be a regular member and a VIP member. A VIP member has additional information such as the starting date of VIP status and percentage of discount.
Is this Entity diagram correct? This is so fracking confusing. I've built this diagram on just intuition rather a systematic approach they teach in a textbook. I still can't wrap my head around the many-to-one relation, weak entities, foreign keys.
There's a fair article on ERDs on Wikipedia.
When you're starting a new ERD - whether it's hand-drawn or computer-drawn - you should focus first on the entities (entity sets). Add the relationships in and then worry about fleshing out your non-key predicates. When you get some experience with ERDs you'll get to the point where you won't need much more work to achieve normalization. It will start to come naturally to you.
There are probably quite a few changes that you'll want to make to your diagram. Since this may be homework, I'll give you an alternative diagram to consider:
This model takes a more sophisticated view of your rules, for example:
Songs can appear many times on the same CD and on different CDs.
A song can be performed by multiple artists within a given track.
Producers can cooperate on a CD.
None of these are necessarily right for your model. It depends on your business rules.
Compare your model with this one and ask yourself what is different and why you might want to take one approach or the other.
take all the major concepts, draw a box for each
in the box put the name of the major concept, like SONG then an underline
under the major concept, list all the attributes like NAME
draw lines from one box to another where those concepts are linked (usually through an attribute) like line from CD to SONG
I'm the one-man dev team on a fledgling military history website. One aspect of the site is a catalog of ~1,200 individual battles, including the nations & formations (regiments, divisions, etc) which took part.
The formation information (as well as the other battle info) was manually imported from a series of books by a 10-man volunteer team. The formations were listed in groups with varying formatting and abbreviation patterns. At the time I set up the data collection forms I couldn't think of a good way to process that data... and elected to store it all as strings in the MySQL database and sort it out later.
Well, "later" - as it tends to happen - has arrived. :-)
Each battle has 2+ records in the database - one for each nation that participated. Each record has a formations text string listing the formations present as the volunteer chose to add them.
Some real examples:
39th Grenadier Rgmt, 26th Volksgrenadier Division
2nd Luftwaffe Field Division, 246th Infantry Division
247th Rifle Division, 255th Tank Brigade
2nd Luftwaffe Field Division, SS Cavalry Division
28th Tank Brigade, 158th Rifle Division, 135th Rifle Division, 81st Tank Brigade, 242nd Tank Brigade
78th Infantry Division
3rd Kure Special Naval Landing Force, Tulagi Seaplane Base personnel
1st Battalion 505th Infantry Regiment
The ultimate goal is for each individual force to have an ID, so that its participation can be traced throughout the battle database. Formation hierarchy, such as the final item above 1st Battalion (of the) 505th Infantry Regiment also needs to be preserved. In that case, 1st Battalion and 505th Infantry Regiment would be split, but 1st Battalion would be flagged as belonging to the 505th.
In database terms, I think I want to pull the formation field out of the current battle info table and create three new tables:
FORMATION
[id] [name]
FORMATION_HIERARCHY
[id] [parent] [child]
FORMATION_BATTLE
[f_id] [battle_id]
It's simple to explain, but complicated to enact.
What I'm looking for from the SO community is just some tips on how best to tackle this problem. Ideally there's some sort of method to solving this that I'm not aware of. However, as a last resort, I could always code a classification framework and call my volunteers back to sort through 2,500+ records...
You've tagged your question as PHP related - but it's not.
You are proposing substituting the real identifiers with surrogate keys (ids) however the real identifiers are intrinsically unique - so you're just making your data structure more complicated than it needs to be. Having said that, the leaf part of the hierarchy may only be unique within the scope of the parent node.
The most important question you need to address is whether the formation tree is always going to be two levels. I suspect that sometimes it may be one and sometimes it may be more than 2. The structure you propose is not going to work very well with variable depth trees.
This may help:
http://articles.sitepoint.com/article/hierarchical-data-database
C.
I want to design a database about bus stations. There're about 60 buses in the city, each of them contains these informations:
BusID
BusName
Lists of stations in the way (forward and back)
This database must be efficient in searching, for example, when user want to list buses which are go through A and B stations, it must run quickly.
In my first thought, I want to put stations in a seperate table, includes StationId and Station, and then list of stations will contains those StationIds. I guest it may work, but not sure that it's efficient.
How can I design this database?
Thank you very much.
Have you looked at Database Answers to see if there is a schema that fits your requirements?
I had to solve this problem and I used this :
Line
number
name
Station
name
latitude
longitude
is_terminal
Holiday
date
description
Route
line_id
from_terminal : station_id
to_terminal : station_id
Route schedule
route_id
is_holiday_schedule
starting_at
Route stop
route_id
station_id
elapsed_time_from_start : in minutes
Does it looks good for you ?
Some random thoughts based on travel on London buses In My Youth, because this could be quite complex I think.
You might need entities for the following:
Bus -- the physical entity, with a particular model (ie. particular seating capacity and disabled access, and dimensions etc) and VIN.
Bus stop -- the location at which a bus stops. Usually bus stops come in pairs, one for each side of the road, but sometimes they are on a one-way road.
Route -- a sequence of bus stops and the route between them (multiple possible roads exist). Sometimes buses do not run the entire route, or skip stops (fast service). Is a route just one direction, or is it both? Maybe a route is actually a loop, not a there-and-back.
Service -- a bus following a certain route
Scheduled Run -- an event when a bus on a particular service follows a particular route. It starts at some part of the route, ends at another part, and maybe skips certain stops (see 3).
Actual Run -- a particular bus followed a particular scheduled run. What time did it start, what time did it get to particular stops, how many people got on and off, what kind of ticket did they have?
(This sounds like homework, so I won't give a full answer.)
It seems like you just need a many-to-many relationship between buses and stops using 3 tables. A query with two inner joins will give you the buses that stop at two specific stops.
I'd hack it.
bus_id int
path varchar(max)
If a bus goes through the following stations (in this order):
01
03
09
17
28
Then I'd put in a record where path was set to
'-01-03-09-17-28-'
When someone wants to find a bus to get from station 03 to 28, then my select statement is
select * from buses where path like '%-03-%-28-%'
Not scalable, not elegant, but dead simple and won't churn through tables like mad when trying to find a route. Of course, it only works if there's a single bus that goes through the two stations in question.
what you have thought is good, in some cases it may or may not be efficient. I think that yo u should create tables as table1(BusID, BusName) table 2(Station List, Bus Id). I think this would would help. And try to use joins between these two tables to get the result. One more thing if possible try to normalize the tables that would help you.
I'd go for 3 tables :
bus
stations
bus_stations
"bus" for what the name stands for, "stations" for the station id's and names, and "bus_stations" to connnect those other 2 tables, wich would have bus_id, station_id_from station_id_to
This is probably more complex that you really need, but if, in the furure, you need to know the full trajectory of a bus, and also, from witch station one bus comes when it goes to "B station", will be usefull.
60 buses will not make that much impact in performance though.