I'm modelling an ontology in SQL using a tree to indicate relations between concepts.
My problem is how to disambiguate concepts in a graph/tree without replicating concepts.
Eg. I have the concept of courses: "karate", "sailing" (lessons one can take from instructors) and places: "gym", "boat club" where these courses can be taken. In the graph it will be:
gym boat club
has has
courses
of of
karate sailing
How can I model this graph to avoid boat club having karate courses and without duplicating the concept of courses?
Thanks!
I would turn the whole data architecture around and think about this as a graph. Have a table for all the concepts (nodes) - gym, boat club, courses, karate, sailing - and another table to create the links (vertices) between them. That table looks something like:
Links
from (concept foreign key)
to (concept foreign key)
link_type (has/of/etc)
It may take a lot more SQL to build up all your information in memory, but this schema will handle these relationships simply.
The table that contains the data Karate and Sailing would contain the primary keys for the other two tables as foreign keys. This would allow for you to have as many of each data type as you like while still being able to traverse the tables to get your information.
Related
I have an ER diagram, shown below.
I need help to create a relational database. To explain the ER, I have Services and service has 1-6 objectives and each objective can match up to 1-8 goals. So the relationship between services and objectives is 1 to many (1-6) and the relationship between objectives is also 1 to many (1-8).
This is what I have so far (* = primary key)
Goals: (GID*, Goal_statement)
Objectives (OID*, Objective_statement)
Services (SID*, Service_Name)
I have to create an PHP script and display the services and then when I click a service, I will be redirected to show its objectives and the related Goals to the objectives. How can I show this? Do I have to create a table for MATCH and HAVE?
No, you don't need joining tables in this case. One service can have many objectives, and one objective can have many goals. That's two 1:many relationships, so all you need is a foreign key in each of the "has" tables.
Thus, you'll also need these columns:
service.objective_id (so a service can specify which objective it is related to)
objective.goal.id (so an objective can specify which goal it is related to)
To create your web application, you'll need to write some SQL, which you can decide before you write the PHP. It sounds like you will need:
A list of services (simple SELECT)
A list of objectives and their goals, given a service ID (a SELECT with an INNER JOIN)
I'm currently working on an app backend (business directory). Main "actor" is an "Entry", which will have:
- main category
- subcategory
- tags (instead of unlimited sub-levels of division)
I'm pretty new to OOP but I still want to use it here. The database is MySql and I'll be using PDO.
In an attempt to figure out what database table structure should I use in order to support the above classification of entries, I was thinking about a solution that Wordpress uses - establish relationship between an entry and cats/subcats/tags through several tables (terms, taxonomies, relationships). What keeps me from this solution at the moment is the fact that each relationship of any kind is represented by a row in the relationships table. Given 50,000 entries I would have, attaching to a particular entry: main cat, subcat and up to 15 tags might slow down the app (or I am wrong)?
I then learned a bit about Table Data Gateway which seemed an excellent solution because I liked the idea of having one table per a class but then I read there is virtually no way of successful combating the impedence missmatch between the OOP and relational-mapping.
Are there any other approaches that you may see fit for this situation? I think I will be going with:
tblentry
tblcategory
tblsubcategory
tbltag
structure. Relationships would be based on the parent IDs but I+'m wondering is that enough? Can I be using foreign key and cascade delete options here (that is something I am not too familiar with and it seems to me as a more intuitive way of having relationships between the elements in tables)?
having a table where you store the relationship between your table is a good idea, and through indexes and careful thinking you can achieve very fast results.
since each entry must represent a different kind of link between two entities (subcategory to main entry, tag to subcategory) you need at least (and at the very most) three fields:
id1 (or the unique id of the first entity)
linkid (linking to a fourth table where each link is described)
id2 (or the unique id of the second entity)
those three fields can and should be indexed.
now the fourth table to achieve this kind of many-to-many relationship will describe the nature of the link. since many different type of relationship will exist in the table, you can't keep what the type is (child of, tag of, parent of) in the same table.
that fourth table (reference) could look like this:
id nature table1 table2
1 parent of entry tags
2 tag of tags entry
the table 1 field tells you which table the first id refers to, likewise with table2
the id is the number between the two fields in your relationship table. only the id field should be indexed. the nature field is more for the human reader then for joining tables or organizing data
So I'm a visual designer type guy who has learned a respectable amount of PHP and a little SQL.
I am putting together a personal multimedia portfolio site. I'm using CI and loving it. The problem is I don't know squat about DB design and I keep rewriting (and breaking) my tables. Here is what I need.
I have a table to store the projects:
I want to do fulltext searcheson titles and descriptions so I think this needs to be MyISAM
PROJECTS
id
name (admin-only human readable)
title (headline for visitors to read)
description
date (the date the project was finished)
posted (timestamp when the project was posted)
Then I need tags:
I think I've figured this out. from researching.
TAGS
tag_id
tag_name
PROJECT_TAGS
project_id (foreign key PROJECTS TABLE)
tag_id (foreign key TAGS TABLE)
Here is the problem I have FOUR media types; Photo Albums, Flash Apps, Print Pieces, and Website Designs. no project can be of two types because (with one exception) they all require different logic to be displayed in the view. I am not sure whether to put the media type in the project table and join directly to the types table or use an intermediate table to define the relationships like the tags. I also thinking about parent-types/sub-types i.e.; Blogs, Projects - Flash, Projects - Web. I would really appreciate some direction.
Also maybe some help on how to efficiently query for the projects with the given solution.
The first think to address is your database engine, MyISAM. The database engine is how MySQL stores the data. For more information regarding MyISAM you can view: http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html. If you want to have referential integrity (which is recommended), you want your database engine to be InnoDB (http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html). InnoDB allows you to create foreign keys and enforce that foreign key relationship (I found out the hard way the MyISAM does not). MyISAM is the default engine for MySQL databases. If you are using phpMyAdmin (which is a highly recommended tool for MySQL and PHP development), you can easily change the engine type of the database (See: http://www.electrictoolbox.com/mysql-change-table-storage-engine/).
With that said, searches or queries can be done in both MyISAM and InnoDB database engines. You can also index the columns to make search queries (SELECT statements) faster, but the trade off will be that INSERT statements will take longer. If you database is not huge (i.e. millions of records), you shouldn't see a noticeable difference though.
In terms of your design, there are several things to address. The first thing to understand is an entity relationship diagram or an ERD. This is a diagram of your tables and their corresponding relationships.
There are several types of relationships that can exist: a one-to-one relationship, a one-to-many relationship, a many-to-many relationship, and a hierarchical or recursive relationship . A many-to-many relationship is the most complicated and cannot be produced directly within the database and must be resolved with an intermittent table (I will explain further with an example).
A one-to-one relationship is straightforward. An example of this is if you have an employee table with a list of all employees and a salary table with a list of all salaries. One employee can only have one salary and one salary can only belong to one employee.
With that being said, another element to add to the mix is cardinality. Cardinality refers to whether or not the relationship may exist or must exist. In the previous example of an employee, there has to be a relationship between the salary and the employee (or else the employee may not be paid). This the relationship is read as, an employee must have one and only one salary and a salary may or may not have one and only one employee (as a salary can exist without belonging to an employee).
The phrases "one and only one" refers to it being a one-to-one relationship. The phrases "must" and "may or may not" referring to a relationship requiring to exist or not being required. This translates into the design as my foreign key of salary id in the employee table cannot be null and in the salary table there is no foreign key referencing the employee.
EMPLOYEE
id PRIMARY KEY
name VARCHAR(100)
salary_id NOT NULL UNIQUE
SALARY
id PRIMARY KEY
amount INTEGER NOT NULL
The one-to-many relationship is defined as the potential of having more than one. For example, relating to your portfolio, a client may have one or more projects. Thus the foreign key field in the projects table client_id cannot be unique as it may be repeated.
The many-to-many relationship is defined where more than one can both ways. For example, as you have correctly shown, projects may have one or more tags and tags may assigned to one or more projects. Thus, you need the PROJECT_TAGS table to resolve that many-to-many.
In regards to addressing your question directly, you will want to create a separate media type table and if any potential exists whatsoever where a project is can be associated to multiple types, you would want to have an intermittent table and could add a field to the project_media_type table called primary_type which would allow you to distinguish the project type as primarily that media type although it could fall under other categories if you were to filter by category.
This brings me to recursive relationships. Because you have the potential to have a recursive relationship or media_types you will want to add a field called parent_id. You would add a foreign key index to parent_id referencing the id of the media_type table. It must allow nulls as all of your top level parent media_types will have a null value for parent_id. Thus to select all parent media_types you could use:
SELECT * FROM media_type WHERE parent_id IS NULL
Then, to get the children you loop through each of the parents and could use the following query:
SELECT * FROM media_type WHERE parent_id = {$media_type_row->id}
This would need to be in a recursive function so you loop until there are no more children. An example of this using PHP related to hierarchical categories can be viewed at recursive function category database.
I hope this helps and know it's a lot but essentially, I tried to highlight a whole semester of database design and modeling. If you need any more information, I can attach an example ERD as well.
Another posibble idea is to add columns to projects table that would satisfy all media types needs and then while editting data you will use only certain columns needed for given media type.
That would be more database efficient (less joins).
If your media types are not very different in columns you need I would choose that aproach.
If they differ a lot, I would choose #cosmicsafari recommendation.
Why don't you take whats common to all and put that in a table & have the specific stuff in tables themelves, that way you can search through all the titles & descriptions in one.
Basic Table
- ID int
- Name varchar()
- Title varchar()
etc
Blogs
-ID int (just an auto_increment key)
-basicID int (this matches the id of the item in the basic table)
etc
Have one for each media type. That way you can do a search on all the descriptions & titles at the one time and load the appropriate data when the person clicked through the link from a search page. (I assume thats the sort of functionality you mean when you say you want to be able to let people search.)
I have two tables that look as Follows:
Person (Table Name)
Name1/Phone1/Email1/Address1/Organization1/Notes1 (Fields)
Organization (Table Name)
Organization1/Phone2/Email2/Address2/Web2/Notes2 (Fields)
Organization1 is the only field in common between the two tables.
When I display data on a person, I want to also check and see if there is data on their organization and display it as well if it exists. I'm using PHP to interface with mySQL.
You need to JOIN the tables.
SELECT * FROM Person LEFT JOIN Organization ON Person.Organization = Organization.Name;
This assumes the relationship is the Organization Name. I've done a LEFT JOIN since you said if exists. Check out this tutorial for more detail on joining tables.
Note: I agree and would recommend making your database more relational by adding Primary Keys and using them as Foreign Keys in your other tables.
This post is an explanation of relations, not code for you to use. If you want that, look elsewhere
Well, connections between tables are called relations. There are 3 types of relations.
1) One -> One - This type of relation means 1 row is related to 1 other row in a different table
2) One -> Many - This type of relation means 1 row is related to a variable number of rows in a different table.
An example may be A folder can have multiple files, but a file can't have multiple folders. So in this case the 1 would be the folder, and the many would be the files.
3) Many -> Many - This type of relation means many rows can relate to many other rows.
An example may be labels. You can label many things the same name (desk appliance for example), and each thing can have multiple labels (a lamp can have both desk appliance & light labels).
.
So now that you know the different relations, we will go into your question. The relation you are looking at is a one to many, one corporation can have many people, but a person can only have one corporation. I suppose a person could work for multiple people, but that is much more complex (so we'll skip it).
One to many relations are by far the most common, and are pretty easy to do. This is where joins come in (left, right, and inner joins). Tizag has an excellent tutorial on joins here: http://www.tizag.com/sqlTutorial/sqljoin.php.
Hope that helps.
You should use a foreign key, but you need to use the InnoDB storage engine (MyISAM does not support foreign keys yet).
Make your tables look something like this:
Person_ID, Name, Phone, Email, Address, Organisation_ID, Notes (or if you have multiple notes, create a seperate table that maps person_id to a note).
Organisation_ID, Name, Phone, Email, Address, Web, Notes.
Select your person, then if Organisation_ID exists, select the Organisation where Organisation_ID equals the ID you obtained from the person row.
I need to build a family tree in php and MySQL. I'm pretty surprised at the lack of open source customizable html family tree-building software there is out there, but I digress. I have spent a lot of time reading about storing MySQL digraphs and family trees. Everything makes sense to me: have a table with nodes (people) and a table with edges (relationships).
The only problem I have is I'm not sure of the best way to store relationships that are not necessarily adjacent, for example sibling and grandparent relationships. At first I didn't think this would be a big deal because I can just invisibly enforce a parent (everyone has parents) that would resolve these connections.
However, I also need to be able to store relationships that may not have a common parent such as romantic partners. Everything I have read suggests a parent-child relationship, but since romantic partners do not share a common parent (hopefully), I'm not sure how to store it in the edges table. Should I use a different table, or what? If it's in the same table, how do I represent this? As long as I am doing this with non-familiar relationships, I might as well do it with family too.
To sum up, three questions:
How do I represent lateral relationships?
If a lateral relationship has a common parent, how do I store it? Should this be a family flag on the table where other lateral relationships are stored?
How do I store parent-child relationships where the child is two or more edges away (a grandparent), but the immediate parent is unavailable?
Any help is appreciated, and if anyone has any suggestion for some javascript/html family tree building software, that would be wonderful.
An idea that comes from the Geneapro schema and RootsMagic.
person
------
person_id
name (etc)
life_event_types
----------------
life_event_type_id
life_event_type_description (divorce, marriage, birth, death)
life_events
-----------
life_event_id
life_event_type_id
life_event_description
life_event_date
life_event_roles
----------------
life_event_role_id
life_event_role (mother, father, child)
person_event_role
-----------------
person_id - who
life_event_id - what happened
life_event_role_id - what this person did
So you could have a life event of type "birth", and the role_id tells you who were the parents, and who was the child. This can be extended to marriages, deaths, divorces, foster parents, surrogate parents (where you might have 3 or 4 parents with a very complicated relationship), etc.
As for storing more distant relationships, you can calculate these. For example, you can calculate the Father of anybody by getting the person who has the 'father' role with a matching event_id. You can then get the father of that person, and you have the grandfather of the original person. Anywhere that somebody is unknown, create the person with unknown data.
person
-------
person_id
other_stuff
relation
----------
person_id_1
person_id_2
relationship_type
begin_dt
end_dt
just populate the relationship type with any value you are interested in. (FK to some picklist would be great)
I put the dates on for an interesting subdiscussion/thought provokation.
The GEDCOM data model and the Gramps data model are two of the most popular formats for exchanging geneological data between different tools. Using either of these data models should both (1) make your tool more compatible with other tools and (2) ensure that your data model is compabible with many special cases, considering both data models are specially designed to deal with geneological data.
Tools like Oxy-Gen or the Gramps PHP exporter should get you on your way with respect to how to import GEDCOM data into a database.
For more details, see also my answer to “Family Tree” Data Structure.