<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Business Rule: Only One Clerk per Department &#8211; 11g Style</title>
	<atom:link href="http://technology.amis.nl/2008/12/19/business-rule-only-one-clerk-per-department-11g-style/feed/" rel="self" type="application/rss+xml" />
	<link>http://technology.amis.nl/2008/12/19/business-rule-only-one-clerk-per-department-11g-style/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=business-rule-only-one-clerk-per-department-11g-style</link>
	<description></description>
	<lastBuildDate>Tue, 11 Jun 2013 22:09:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Toon Koppelaars</title>
		<link>http://technology.amis.nl/2008/12/19/business-rule-only-one-clerk-per-department-11g-style/#comment-5635</link>
		<dc:creator>Toon Koppelaars</dc:creator>
		<pubDate>Sat, 20 Dec 2008 10:39:32 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/4497/business-rule-only-one-clerk-per-department-11g-style#comment-5635</guid>
		<description><![CDATA[John,

I get the feeling, also from a discussion earlier this month at the UKOUG, that there is a &#039;tribe of database designers&#039; that believe that if a business rule cannot be expressed/modellted through PK&#039;s, UK&#039;s, and FK&#039;s, then a) the &quot;rule&quot; is not a business rule, and/or b) your design is flawed and should be amended such that it becomes expresseable through UK/PK/FK&#039;s.

Reading your response I got curious: are you one of those tribe-members too?

Toon]]></description>
		<content:encoded><![CDATA[<p>John,</p>
<p>I get the feeling, also from a discussion earlier this month at the UKOUG, that there is a &#8216;tribe of database designers&#8217; that believe that if a business rule cannot be expressed/modellted through PK&#8217;s, UK&#8217;s, and FK&#8217;s, then a) the &#8220;rule&#8221; is not a business rule, and/or b) your design is flawed and should be amended such that it becomes expresseable through UK/PK/FK&#8217;s.</p>
<p>Reading your response I got curious: are you one of those tribe-members too?</p>
<p>Toon</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Nuijten</title>
		<link>http://technology.amis.nl/2008/12/19/business-rule-only-one-clerk-per-department-11g-style/#comment-5634</link>
		<dc:creator>Alex Nuijten</dc:creator>
		<pubDate>Sat, 20 Dec 2008 06:36:51 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/4497/business-rule-only-one-clerk-per-department-11g-style#comment-5634</guid>
		<description><![CDATA[Thanks for your comments, John.
You would probably call this technique a &quot;hack&quot;... ;-) I&#039;m curious as to why (the reason) you call it &quot;the wrong way to enforce&quot; this Business Rule. It&#039;s a sure fire way to implement this rule, there is no getting around it.
The solutions you propose do not implement the Business Rule. In both solutions you expect the end user to know the rule. There is no way you can stop them for selecting a MANAGER or SALESMAN to be used as your DEPARTMENT_CLERK (first solution) or in the intersection (second solution). How do you make sure that your end user only picks those Employees who JOB is CLERK? What if a JOB changes, someone gets promoted from CLERK to OFFICE MANAGER?
If you assume that your end users only select CLERKs, than you might as well not implement this Business Rule.
It can be done using your solutions, but you are missing a vital ingredient, a VIRTUAL COLUMN. Create a Virutal Column which shows the EMPNO only when the JOB = CLERK and use this virtual column as the foreign key (in your first and second solution)... however.... in order to use it as a Foreign Key, the column needs to be Unique... And when you create this column unique, you might as well do it the way I showed you ;-)
An example of the latter can be found here: http://nuijten.blogspot.com/2008/12/business-rule-only-use-active-records.html]]></description>
		<content:encoded><![CDATA[<p>Thanks for your comments, John.<br />
You would probably call this technique a &#8220;hack&#8221;&#8230; <img src='http://technology.amis.nl/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />  I&#8217;m curious as to why (the reason) you call it &#8220;the wrong way to enforce&#8221; this Business Rule. It&#8217;s a sure fire way to implement this rule, there is no getting around it.<br />
The solutions you propose do not implement the Business Rule. In both solutions you expect the end user to know the rule. There is no way you can stop them for selecting a MANAGER or SALESMAN to be used as your DEPARTMENT_CLERK (first solution) or in the intersection (second solution). How do you make sure that your end user only picks those Employees who JOB is CLERK? What if a JOB changes, someone gets promoted from CLERK to OFFICE MANAGER?<br />
If you assume that your end users only select CLERKs, than you might as well not implement this Business Rule.<br />
It can be done using your solutions, but you are missing a vital ingredient, a VIRTUAL COLUMN. Create a Virutal Column which shows the EMPNO only when the JOB = CLERK and use this virtual column as the foreign key (in your first and second solution)&#8230; however&#8230;. in order to use it as a Foreign Key, the column needs to be Unique&#8230; And when you create this column unique, you might as well do it the way I showed you <img src='http://technology.amis.nl/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /><br />
An example of the latter can be found here: <a href="http://nuijten.blogspot.com/2008/12/business-rule-only-use-active-records.html" rel="nofollow">http://nuijten.blogspot.com/2008/12/business-rule-only-use-active-records.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Flack</title>
		<link>http://technology.amis.nl/2008/12/19/business-rule-only-one-clerk-per-department-11g-style/#comment-5633</link>
		<dc:creator>John Flack</dc:creator>
		<pubDate>Fri, 19 Dec 2008 20:30:58 +0000</pubDate>
		<guid isPermaLink="false">http://technology.amis.nl/blog/4497/business-rule-only-one-clerk-per-department-11g-style#comment-5633</guid>
		<description><![CDATA[As far as I&#039;m concerned, this is the wrong way to enforce one clerk per department.  There are two possible right ways:
1.  Change DEPT to add a foreign key to EMP named DEPARTMENT_CLERK.  This is the EMPNO of this department&#039;s one and only CLERK.  Make it NOT NULL to require each department to have a clerk.
2.  Add a table called CLERKS as an intersection between DEPT and EMP with foreign keys to each or as a duplicate of EMP.  Put all the clerks in this table.  Make CLERKS.DEPTNO unique.]]></description>
		<content:encoded><![CDATA[<p>As far as I&#8217;m concerned, this is the wrong way to enforce one clerk per department.  There are two possible right ways:<br />
1.  Change DEPT to add a foreign key to EMP named DEPARTMENT_CLERK.  This is the EMPNO of this department&#8217;s one and only CLERK.  Make it NOT NULL to require each department to have a clerk.<br />
2.  Add a table called CLERKS as an intersection between DEPT and EMP with foreign keys to each or as a duplicate of EMP.  Put all the clerks in this table.  Make CLERKS.DEPTNO unique.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
